home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group94a.txt / 000127_icon-group-sender _Wed May 11 03:33:55 1994.msg < prev    next >
Internet Message Format  |  1994-08-19  |  2KB
  1. Received: by cheltenham.cs.arizona.edu; Wed, 11 May 1994 08:29:54 MST
  2. Date: Wed, 11 May 94 03:33:55 CDT
  3. From: jeffery@ringer.cs.utsa.edu (Clinton L. Jeffery)
  4. Message-Id: <9405110833.AA18491@ringer.cs.utsa.edu.sunset>
  5. To: perry@cynic.org
  6. Cc: icon-group@cs.arizona.edu
  7. In-Reply-To: Perry The Cynic's message of Tue, 10 May 94 15:19:18 PDT <m0q1091-00001fC@sutr.cynic.org>
  8. Subject: Incrementally loading implementations?
  9. Content-Length: 1047
  10. Status: R
  11. Errors-To: icon-group-errors@cs.arizona.edu
  12.  
  13.    I would like to know how hard it would be to incrementally load
  14.    ICON binary files (esp. the .u[12] type files for the interpreter).
  15.    Has anyone done this? Has anyone tried and found it too hard?
  16.  
  17. Icon 8.10 and above come with a facility I wrote (turned off by default;
  18. an experimental research product so far) that allows entire icode files to be
  19. loaded as co-expressions; it sounds like you want not just dynamic *loading*
  20. but also dynamic *linking* which will require further modifications to Icon
  21. to make various global data areas (the global variables, the record field
  22. table, etc) extensible as new code is loaded and linked in.
  23.  
  24. It is not un-doable (SmallTalk does it--it must be easy (just kidding))
  25. and I would love to see it.  On the other hand, it would require intimate
  26. knowledge of portions of the interpreter code, so its not a casual project.
  27. I've thought about it a fair amount and would be happy to advise you on it.
  28.  
  29. Clint Jeffery
  30. cjeffery@cs.arizona.edu, jeffery@ringer.cs.utsa.edu
  31. The University of Texas at San Antonio
  32.